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Report of the Second Ad Hoc Network Management Review Group 


Status of this Memo 


This RFC reports an official Internet Activities Board (IAB) policy 


position on the treatment of Network Management in the Internet. This 


RFC presents the results and recommendations of the second Ad Hoc 


Network Management Review on June 12, 1989. The results of the first 
such meeting were reported in RFC 1052 [1]. This report was approved 


and its recommendations adopted by the IAB as assembled on July 11- 
13, 1989. Distribution of this memo is unlimited. 


INTRODUCTION 


On February 29, 1988, an Ad Hoc Network Management Review Group was 
convened to consider the state of network management technology for 
the Internet and to make recommendations to the Internet Activities 
Board as to network management policy. The outcome of that meeting 


was summarized in RFC 1052 and essentially established a framework in 


which two network management protocols now known respectively as 
Simple Network Management Protocol (SNMP) and Common Management 
Information Protocol on TCP (CMOT) were selected for further work. 
Subsequently, both SNMP [6] and CMOT [5] were advanced to Draft- 
Standard/Recommended status for use in the Internet [SNMP: RFC 1098, 
CMOT: RFC 1095]. 


Simultaneously, it was agreed to establish a working group to 
coordinate the definition and specification of managed objects to be 
used in common with either protocol. In addition, it was agreed to 
use the then current ISO Structure of Management Information (SMI) 
specification as a reference standard to guide the naming and 
abstraction conventions that would be followed in constructing the 
common Internet Management Information Base (MIB). The Internet 
versions of SMI and MIB were specified in RFC 1065 [2] and RFC 1066 
[3] respectively. 


In the intervening fifteen months, considerable progress has been 


made in the specification of a common Management Information Base and 
in the implementation, deployment and use of network management tools 


in the Internet. 
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The current public subtree of the Internet MIB contains roughly 100 
variables (i.e., managed objects) agreed by the SNMP and CMOT working 
groups as mandatory for Internet network management. The June 12, 
1989 meeting which this document reports was convened to review the 
progress to date, to determine whether actions were needed to foster 
further evolution of network management tools and to recommend 
specific actions in this area to the IAB. 


SNMP STATUS 


Immediately after the meeting reported in RFC 1052, a group was 
convened to make extensions and changes to the predecessor to SNMP: 
Simple Gateway Monitoring Protocol. A "connectathon" was held at 
NYSERNet, an RFC published, and demonstrations of network management 
tools using SNMP were offered in the Fall at Interop 88 [a conference 
and show presented by Advanced Computing Environments (ACE)]. The 
protocol is in use in a number of networks within the Internet as 
well as in private packet networks internationally. A number of 
vendor implementations are in the field (e.g., cisco Systems, 
Proteon, The Wollongong Group), vendor independent reference 
implementations (e.g., NYSERNet, Case and Key in Tennessee) along 
with some freely available versions (e.g., MIT, CMU). 


It is important to note that while the common Internet Management 
Information Base has roughly 100 variables, a typical SNMP monitoring 
system may support anywhere from 100 to 200 ADDITIONAL objects which 
have been defined in private or experimental MIB space. Many of 
these are device or protocol dependent variables. 


Scaling to include larger numbers of monitored objects and subsystems 
remains a challenge. It was observed that fault monitoring was 
easier to scale than performance and configuration monitoring, since 
the former may operate on an exception basis while the latter is more 
likely to require periodic reporting. 


CMOT STATUS 


RFC 1095 (CMOT) was recently published and built upon experience 
gained earlier with prototype implementations demonstrated at Interop 
88 in the Fall of that year. The present specification for CMOT is 
based on the ISO Draft International Standard version of Common 
Management Information Protocol (CMIP). The CMIP is being moved to 
International Standard status, though the precise timing is not 
perfectly clear. It will happen late in 1989 or perhaps in the first 
quarter of 1990. Some changes will be made to correct known errors 
and the CMIP document itself will probably be restructured. 


During this discussion, it was pointed out that there is much to 
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network management which is not addressed by either the CMOT or the 
SNMP specifications: for example, down loading of software, 
configuration management and user access control. Authentication of 
the source of network management commands and responses is another 
area important to providers and users of network management tools. 


The National Institute for Standards and Technology (NIST) is 
sponsoring the development of implementors’ agreements on the 
functional behavior of network management tools including, inter 
alia, logging, event reporting, error reporting, structured object 
management, and alarm reporting. 


Although at the time of the meeting, there were no publicly available 
implementations of CMOT reported, developments were reportedly 
planned by a number of vendors both in the form of agents and network 
management tools. The University of Wisconsin plans to demonstrate 
CMOT using the ISODE software at Interop 89 [(tm) ACE] in September 
1989. 


MIB AND SMI STATUS 


In the Fall of 1988, two RFCs were published (1065 and 1066) to 
specify the Structure of Management Information (SMI) and the initial 
Internet Management Information Base (MIB) respectively. There were 
some challenges in crafting this set of commonly agreed variables; in 
the end, roughly 100 were agreed and defined as mandatory for 
Internet management. 


It was recognized in this process that the definition of the layer 
BELOW IP was a difficult task. IP is sufficiently simple and general 
that it has been moved in encapsulated form over many media including 
the MAC level of various local nets, X.25 packet level, serial line 
protocols, multiplexors, tunnels and, it is rumored, tin cans and 
string. 


At the Transport level, specifically for TCP, it was observed that 
information about the transient status of connections was potentially 
inaccessible to the network management tools since the loss of a TCP 
connection typically meant loss of its Transmission Control Block 
(status block) just when you wanted to look back into the history of 
its state. Countervailing this observation was evidence that looking 
at TCBs with network management tools yielded far more insight into 
the transient behavior of TCP than looking at aggregated network 
statistics. 


It was clear from the discussion that there is strong interest in 
extending the variables accessible via network management tools. 
Adding new devices, new higher level protocols and the ability to 
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manipulate configuration information were high on the list of 
desirable extensions, although several participants felt that this 
desire needed some moderation. 


A vital, but unsettled research area has to do with relationships 
among groups of monitored variables. A particular implementation may 
have IP operating atop X.25. The problem is to be able to make 
queries about the condition of monitored variables so that those for 
the IP level can be correlated with those for a lower layer, for 
instance. This notion of relationship is especially important as 
network devices (including hosts) begin to sport multiple network 
connections and multiple protocol suites operating in parallel. Just 
how the dynamics of such relationships are to be specified, defined 
and instantiated is the research question. What sort of SMI is 
appropriate? What generic structure is needed for the management 
objects? 


Another difficult topic has to do with version numbers for SMI. The 
issue is "which version of MIB is instantiated in this monitored 
system?" As consideration of extensions to the currently agreed SMI 
were contemplated during the last fifteen months, it became apparent 
that the question of versions was central. 


Not far behind was the question of functionality of the underlying 
support protocols (SNMP and CMOT). The RFC 1052 recommendation was 
to tightly link the MIB/SMI, keeping only one such definition for 
both protocols. In theory, this plan would make it easier to move 
from one protocol base to another. In practice, it appears to have 
stifled exploration of new variable and function definitions in 
operating network environments. This point needs to be underscored: 
it is essential for the Internet community to have the freedom to 
explore the utility of the OSI offerings while, at the same time, 
having the freedom to respond to operational needs through the 
definition and use of new MIB variables and SMI features. 


Yet another area still needing development has to do with the 
archiving of operational data collected by means of a network 
management tool. The ISO Common Management Information Service 
(CMIS) specifications do not treat this matter. 


Finally, it was pointed out that registration of managed objects and 
their definitions was still an open area although the NIST has 
apparently made progress through its Network Management Special 
Interest Group (NMSIG) in planning for cataloging of defined 
management information objects. 
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APPLICATION PROGRAMMING INTERFACE (APT) 


It was generally agreed that the actual network management tools 
available to operators, rather than the specifics of the protocols 
supporting the tools, would be the determining factor in the 
effectiveness of any Internet network management system. A brief 
report was offered and discussion ensued on the possibility of 
creating a common application programming interface that could be 
used independent of the specific protocol (CMOT, SNMP, CMIP or 
proprietary) used to transport queries and commands. 


It was acknowledged that the present service interfaces of both SNMP 
and CMIS have limitations (e.g., neither has any sense of time other 
than "now"; this makes it impossible to express queries for 
historical information, or to issue command requests of the form: Do 
X at device Y, beginning in 30 minutes). These limitations hinder 
both SNMP and CMOT from directly offering a comprehensive API for 
network management applications. 


Although some positive sentiment was expressed for defining a kind of 
"super SMI" metalanguage to aid in the the definition of a general 
API, it was not clear whether the current crop of supporting 
protocols had sufficient semantic commonality to be used in this way. 
The matter remains open for investigation. 


NIST ACTIVITIES 


The Ad Hoc Review had the benefit of representatives from NIST who 
are active in the network management area. It was reported that the 
major focus at present is at layers 3 and 4 where objects are being 
defined in accordance with "templates" provided by ISO’s SC21. IEEE 
802 is also pursuing the definition of MIB objects, though not with 
the benefit of the same templates now in use by the NIST NMSIG. The 
layers above transport are just beginning to receive attention. 


It was observed that the Internet SMI is not quite a subset of the 
ISO CMIS SMI. The Internet variable naming conventions are a little 
different and some functionality may vary. There was some 
uncertainty about the treatment of gauges in the Internet SMI and the 
corresponding OSI SMI. [L. Steinberg reported, subsequent to the 
meeting, that gauges latch and counters roll over in the OSI SMI, as 
they appear to do in the Internet SMI - VGC]. 


The general sense of this portion of the discussion was that a 
considerable amount of activity is underway with the sponsorship of 
NIST and that this work is relevant to the Internet community, 
particularly as the time approaches in which coexistence of the OSI 
protocol suite with the existing Internet protocols is the norm. 
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CONCLUSIONS AND RECOMMENDATIONS 


The assembled attendees came to the conclusions enumerated below and 
recommends to the IAB that actions be taken which are consistent with 


these conclusions: 

1. The Internet will exist in a pluralistic protocol stack 
environment and the need to coexist will persist. 

2. Expansion of the common MIB has been impeded by an inability to 
agree on a common, extended SMI. 

3. The Internet community must not ignore the work of other groups 
in the network management area, while at the same time, coping 
with the current operational needs of the Internet (and 
internet) communities. 

4. Until we can gain operational experience with OSI network 
management tools (e.g., with CMIP on TCP or on OSI), we cannot 
specify a plan for coexistence with and transition to use of 
the OSI-based protocols in the Internet. 

Therefore: 

(a) We want to foster an environment for real CMOT/CMIP use. 

(b) We should take action as needed to extend SNMP for operational 
reasons. 

(c) We must preserve the utility of the first agreed common MIB 
(RFC 1066). 

(d) We should develop, separately, experimental and enterprise MIB 
variables and seek opportunity for placing these in the common 
MIB. 

(e) In a coexisting environment, we will need to access the same 
set of variables (e.g., in a given gateway or router) by means 
of more than one protocol (e.g., SNMP, CMIP/TCP, CMIP/CLNP, 
etc.). 

It is recommended to the IAB that the network management efforts 
using SNMP and CMOT be allowed independently to explore new variables 


and potentially non-overlapping SMI definitions for the next 12 
months so as to foster operational deployment and experience with 


these 


network management tools. In essence, it is recommended that 


the binding of SNMP and CMOT to a common MIB/SMI be relaxed for this 
period of exploration. Variables which are NOT supportable in common 
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by both protocols should be defined in the experimental or private 
parts of the MIB definition space. Obviously, care should be taken 
to achieve agreement within each respective working group on any 
variables added to the distinct SNMP and CMOT experimental spaces. 


Specifically, the CMOT working group should extend its MIB and SMI 
definitions in the direction of the OSI/NIST specifications so as to 
bring CMOT into closer alignment with the OSI CMIS design. 


During this period of experimentation, it is strongly recommended 
that the IAB seek opportunities to encourage the introduction of 
Internet elements which use the OSI protocols into the Internet 
environment. Such OSI-based elements offer an opportunity to obtain 
operational experience with monitoring and management support by way 
of the CMIP and CMOT protocols. It is anticipated that network 
management systems based on the OSI Common Management Information 
Service (CMIS) will be developed which use CMIP or CMOT, as 
appropriate, to manage various elements in the Internet. 


It is also recommended that the IAB engage in an active liaison 
effort with the NIST, focusing especially on the question of 
coexistence of the Internet protocols with OSI protocols. If at all 
possible, joint experimental or test-bed efforts should be initiated 
to identify means for supporting this coexistence. 


As necessary, the Internet Engineering Task Force should be directed 
to restructure its network management efforts both to support the 
need for MIB/SMI exploration by the SNMP and CMOT groups and to 
strengthen links between the IETF efforts and those of NIST. 


Finally, it is recommended that the Ad Hoc Review Group be reconvened 
at 6 month intervals to review status and to determine whether 
opportunities for expanding the common MIB/SMI are available. 
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